Fix off-by-one that corrupts a bitmap in remove_smallest/remove_biggest (#359) - #363

Fixes #359.

Problem

For a run/interval container, IntervalStore::remove_smallest(n) and remove_biggest(n) have an off-by-one at the interval where removal stops when n exactly equals that interval's run length:

• remove_smallest does start += amount, moving start to end + 1.
• remove_biggest does end -= amount, moving end to start - 1.

Either way the interval becomes inverted (start > end), and run_len() (end - start + 1) then underflows on the subtraction: a debug-build panic ("attempt to subtract with overflow"), or silent corruption in release. The reporter's example: {0,1,2,4}.remove_smallest(3) should yield {4} but returns a bitmap of length 65537.

Fix

Drop the exactly-consumed interval instead of shrinking it:

• remove_smallest: if last_interval.run_len() < amount becomes <=, so an interval whose whole run is removed is dropped via remove_to += 1 rather than shrunk.
• remove_biggest: if last_interval.run_len() >= amount becomes >, so the exactly-consumed interval falls through to the drain(remove_to..) that removes it, instead of shrinking its end.

Test

Added remove_smallest_exact_interval_boundary and remove_biggest_exact_interval_boundary (the reporter's two cases at the IntervalStore level). Red-green verified with cargo test -p roaring: before the fix both assert against inverted intervals ([3, 2] / [4, 3]); after, they drop the whole interval. The full roaring test suite (including the property tests) passes; rustfmt --check and clippy are clean.